Lambda the Ultimate

A first installment of a booklet by John Barnes titled Safe and Secure Software: An Introduction to Ada 2005.

The purpose of this booklet is to illustrate the ways in which Ada 2005 can help in the construction of reliable software, by illustrating some aspects of its features. It is hoped that it will be of interest to programmers and managers at all levels.

It must be stressed that the discussion is not complete. Each chapter selects a particular topic under the banner of Safe X where Safe is just a brief token to designate both safety and security. For the most critical software, use of the related SPARK language appears to be very beneficial, and this is outlined in Chapter 11.

The introduction is rather amusing, so even non Ada fans may want to take look.

Simply efficient functional reactivity. Conal Elliott.

Functional reactive programming (FRP) has simple and powerful semantics, but has resisted efficient implementation. In particular, most past implementations have used demand-driven sampling, which accommodates FRP's continuous time semantics and fits well with the nature of functional programming. Consequently, values are wastefully recomputed even when inputs don't change, and reaction latency can be as high as the sampling period.

This paper presents a way to implement FRP that combines data- and demand-driven evaluation, in which values are recomputed only when necessary, and reactions are nearly instantaneous. The implementation is rooted in a new simple formulation of FRP and its semantics and so is easy to understand and reason about.

On the road to efficiency and simplicity, we'll meet some old friends (monoids, functors, applicative functors, monads, morphisms, and improving values) and make some new friends (functional future values, reactive normal form, and concurrent “unambiguous choice”).

I'm not sure exactly where to classify this submission to ICFP 2008, but I think many here will be interested in it.

[Chicken-users] macro systems and chicken (long), Alex Shinn, Apr 2008.

There seems to be a lot of confusion in the Chicken
community, and the Lisp community in general, about the
different macro systems, so I thought provide some
background information and discussion of the eggs available
in Chicken and their uses.

A very nice post that provides a historical overview and implementations of a hygienic (swap! a b) macro in different macro systems: syntactic closures, reverse syntactic closures, explicit renaming, syntax-case, and syntax-rules.

I didn't know syntactic closures before, and find their interface and implementation simple and easy to understand. Any reasons why they aren't used more in Scheme?

A Modular Language for Concurrent Programming, September 2006, Technical Report by Peter Grogono and Brian Shearing.

How will programmers respond to the long-promised concurrency revolution, which now appears both inevitable and imminent? One common answer is "by adding threads to objects". This paper presents an alternative answer that we believe will reduce rather than add complexity to the software of the future. Building on the ideas of an earlier generation, we propose a modern programming language based on message passing. A module cannot invoke a method in another module, but can only send data to it. Modules may be constructed from other modules, thus permitting processes within processes. Our goal is to provide the flexibility and expressiveness of concurrent programming while limiting, as much as possible, the complexity caused by nondeterminism.

The principle innovations reported in the paper derive from bringing together ideas -- some well known, but others almost forgotten -- found in the historical software literature, and combining these ideas to solve problems facing modern software developers. In addition, at least one idea reported here appears to be novel, namely the introduction of an interface hierarchy based not on data elements or methods, but on path expressions, on the actual flow of control within a module. It is more natural to classify components of a process-oriented system by control flow rather than data content.

Another novel feature is the integration of unit tests into the source of each component, thus reducing the possibilities for testing to get out of step with development.

The project home page is here.

Conrad Barski has posted a sneak peak from his upcoming Lisp textbook/comic: Land of Lisp.

The first slides may seem unrelated, but boy does the message sting when you reach the ending...

FPers will be quick to note, of course, that this being April Fools' Day the whole thing is a joke and we can all go back to Haskell...

From SC-L:

We would like to invite the community to review and comment on the current version of the CERT C Secure Coding Standard available online at www.securecoding.cert.org before Version 1.0 is published.

Hey, maybe this is also relevant for the curriculum thread.

Back in 2003, Martin Berger conducted a fairly lengthy interview with Robin Milner. The transcript includes some interesting tidbits on the development of ML, CCS, and the pi-calculus. Among other things, you'll find a recounting of how Milner and David Park came up with the idea of bisimulation, a discussion of the rationale behind some of the design decisions Milner and his colleagues made in creating the pi-calculus, and Milner's thoughts on how theory should influence programming languages:

I do care that languages should be informed by theories...I actually think the best way forward for us now is to look at concurrent calculi as modelling theories for modelling interactions, whether they occur in programs or in outside programs...Languages should emerge from that. They should be treated as a part of a modelling theory. Up to now I don't think we had sufficient incentive to make sure that our languages are close to scientific models. It's only with the onset of computation as a global phenomenon that modelling those interactions becomes so scientifically important that it is bound to have its effect on programming languages.

SIGPLAN Workshop on Undergraduate Programming Language Curriculum.

Programming languages play a critical role in computer science by providing a flexible and robust means by which human beings interact with and control computer systems. Programming language design and implementation has advanced significantly in the recent past in response to the increasing pervasiveness of computer science and technology. Unfortunately, higher-education curriculum has not kept pace, and so it does not appropriately reflect the expansive growth and evolution. This lag is a critical challenge because an up-to-date curriculum is essential to prepare a globally competitive workforce, able to generate and to apply new knowledge, and to take the lead in advancing computer science and technology.

The goal of this workshop is to bring together leaders in the field of programming languages with expertise in research, teaching, and industrial use to discuss the role of programming language design, implementation, and application in modern, undergraduate, computer science education. Our objective with this effort is to build a community for these experts to discuss, critically evaluate, and identify the transformational changes needed to best prepare undergraduates to participate in the rapidly changing field of computer science and technology.

In particular, this workshop should provide a forum for the community (1) to evaluate recent changes and likely trends in computing technology and their impact on programming language design, implementation, and application (and vice versa), (2) to discuss the implications of these changes on programming language curricula, and (3) to explore strategies for designing new curricula. For the first task, we will consider trends that include the looming ubiquity of multi-processing systems, the proliferation of domain-specific languages, the increasing diversity of relevant programming languages, infrastructures, and support tools, the growing heterogeneity of device architectures (high-performance computing systems, desktops, game consoles, mobile phones, hand-held devices, etc.), and the increasing complexity of systems (operating, runtime, and application-level). For the second task, we will consider how these trends impact what and how we should be teaching our undergraduates about programming languages. Finally, for the third task, we will explore various tactics for designing new programming language curricula that incorporate the insights from these discussions and yet fit within the constraints of existing undergraduate programs.

We only rarely post links to conference or workshop announcements, but this seems like something worth calling out particular attention to. Many universities use ACM curriculum recommendations to structure their undergraduate programs, so it's very important to make sure that the programming languages recommendations are in good shape.

People usually regard algorithms as more abstract than the programs that implement them. The natural way to formalize this idea is that algorithms are equivalence classes of programs with respect to a suitable equivalence relation. We argue that no such equivalence relation exists.

A bit more philosophical than usual, but the issue is quite relevant to discussions in the field.

It is possible to stipulate any equivalence relation that is considered useful (e.g., equivalence up to local transformations) but the notion of a universally applicable relation is indeed problematic.

Disciple is an explicitly lazy dialect of Haskell which includes:

• first class destructive update of arbitrary data.
• computational effects without the need for state monads.
• type directed field projections.

All this and more through the magic of effect typing.

The wiki page has more information, unfortunately there's no paper yet summarizing the ideas and results. Their effect system is quite interesting. Some of the ideas recently discussed here are implemented in Disciple.

via Haskell Cafe